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METHOD FOR DECODING CHARGING DATA RECORDS IN MOBILE 
TELEPHONE NETWORKS AND THE RELATIVE SYSTEM 
Technical Field 

The present invention tackles the problem of decoding 
5 the so-called Charging Data Records (normally known by the 
acronym CDR) emitted by the nodes of a mobile telephone 
network. 
Background Art 

These charging data records are currently decoded by 
10 employing solutions based on software applications, which, 
for example, decode GSM network records separately from those 
of an associated GPRS network. Specifically, the application 
is developed manually starting from the record coding 
specifications, and each time there is a modification/new 
15 release of the GSM and/or GPRS systems and when new functions 
are added, parts of the software must be to some extent 
rewritten. 

There is consequently a need to provide solutions that 
can decode both GSM and GPRS format records, and for 
20 solutions that take into account the frequent updating of the 
record format after the introduction . of new GSM and GPRS 
network services/performances, as well as the possibility of 
easy extension of the application to new functions such as 
UMTS. 

25 This objective can be reached, according to this 

invention, by using a method that has the features referred 
to specifically in the claims that follow. The invention also 
refers to the relative system . 
Summary of t:he Invention 

3 0 The solution, according to this invention, basically 
envisages the automatic generation of the logic that decodes 
the records. Whereas known solutions include the rewriting of 
the record decoding software whenever variations are 
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introduced by the MSG manufacturer (Mobile Switching Center) 
or SGSN/GGSN (Serving GPRS Support Node and Gateway GPRS 
Support Node) , the solution according to the invention simply 
requires the manufacturer to provide a formal record 
5 description of the ASN.l type (Abstract Syntax Notation One) . 
The solution, according to the invention, then uses this 
description to directly generate the code that decodes the 
data record. As a result, the decoder adaptation times can be 
cut from several weeks to a few days, ma)cing it easy to keep 
10 right up to date with the mobile network's frequent 
alterations . 

The solution, according to the invention, includes the 
decoding of GSM records and GPRS records, which means that a 
single tool can be used on a mixed network employing both 
15 technologies.. This is particularly advantageous if you 
consider that the operators of large-scale mobile telephone 
networks use both technologies in the network, in conditions 
in which the network update is carried out asynchronously. 
The solution, according to the invention, proposes to decode 
2 0 the data records for GSM and GPRS functions, but its main 
features also make it easy and quick to extend the solution 
to other functions such as UMTS. 
Brief Description of Drawings 

The invention is hereafter described, by way of a non- 
25 limiting example only, with reference to the annexed drawings 
wherein : 

- Figure 1 is a functional block diagram illustrating the 
general architecture and the input /output /control 
relationships of a system that operates according to the 

30 invention, and 

- Figure 2 is a flow diagram illustrating the main stages 
into which the method is divided according to the 
invention. 
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Detailed description of the preferred embodiments 

As shown in Figure 1, the illustrated system, referred to 
with the number 10, has a main element, which is a processing 
core 12, destined to input a file to be decoded 14, which 
5 then outputs a corresponding decoded file IS. The system 12 
works on the basis of a decoding logic that is directly self- 
generated from the formal description ASN.l contained in a 
file 2 0 received from the* outside. As already known, the 
description of the records in ASN.l (or equivalent, and 
10 consequently a description *"of the ASN.l type") constitutes a 
set of specifications that describe the coding format of the 
records in ASN.l Notation or equivalent. 

The input or log file 14 contains the records generated 
by the real network equipment (MSG for GSM records or 
15 SGSN/GGSN for GPRS records) in coded hexadecimal format. 

The decoding operation is run on the basis of the set of 
user parameters that characterise the log file, the type of 
record (SGM/GPRS) and the output format. 

In particular, starting from an initial step 100, the 
20 first steps in the operating sequence of the system 10 
include the reading of the parameters sent to output, which 
are : 

- type of record to be decoded: GSM or GPRS (read by the 
system in step 102) , 

25 - name of the log file to be decoded (step 104) , 

- decoding format, i.e. the output format of the decoded file 
(read in step 106); this format may be "long", when the 
decoding, the length and the contents in hexadecimal are 
given for each record field, or short , when only the 

30 decoding is given for each record field, 

- log file containing the records to be decoded (step 108) , 
and 

- formal record description of the ASN.l type (step 110). 
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Depending on the record description, an interpreter, such as 
an ASN.l interpreter, included in the processing core 12 (see 
block 18 in Figure 1) creates and runs a series of procedures 
(collectively referred to as 112) , which in terms of a self- 
5 generation operation, create an updated version of the GSM 
decoder (step 114) or GPRS decoder (step 116) according to 
the type of record read in step 102. 

The type of decoder selected (114 or 116) according to 
the parameter indicating the type of record (step 102) is 
10 further parameterised according to the parameters read in 
steps 104 and 106 (log file name and decoding format) . 

Once the decoder has been updated and programmed, it 
inputs (step 118) the file 14 containing the records to be 
decoded, and then outputs (step 12 0) the file containing the 
15 records decoded in text format. Reference 122 indicates the 
final step in the procedure. 

Naturally, numerous changes can be made to the 
construction and embodiments of the invention envisaged and 
illustrated herein, without however departing from the scope 
2 0 of the present invention. 



